Ever since the advent of ubiquitous wireless networks and GPS satellites, specialized wireless devices have been installed in vehicles to facilitate fleet operations management and in virtually anything that moves or is moved to enable asset tracking. In the art, such devices are commonly called “locator devices”, referencing their basic functionality of locating and reporting a physical position of a vehicle, trailer or any asset. However, functionality of the locator devices is not limited to merely location tracking. The locator devices interface with many kinds of other devices and systems to collect information and data and to control operation of external systems. Although typically intended to be used with wireless networks to communicate with a centralized management system, the locator devices are also typically capable of independent operation in an event of a network failure, for example. In such situations, instead of immediate reporting, the locator devices typically operate according to pre-defined rules and/or store the information they gather in local memory.
When used by fleet operators, the locator devices provide a wealth of useful functions such as efficient vehicle scheduling, dispatching and location management, monitoring driver behaviour and compliance with traffic rules and government regulations, fuel tax recovery, detailed time tracking, and enhanced driver services such as real-time mapping, Internet access, credit card processing, and many others.
In other applications, locator devices of all kinds are often used to track high-value assets ranging from cars and construction equipment to pallet shipments and even small packages.
The use of locator devices in such a variety of applications naturally imposes a myriad of different requirements, both physical (e.g., size, power consumption, processing speed, storage capacity, etc.), and operational (e.g., software functionalities for monitoring, tracking, recording, controlling, etc.). Furthermore, even a single locator device, used for a single application, while having a single set of physical specifications, may have different functional requirements depending on the particular mode or location of use.
To date, manufacturers of the locator devices have not adequately overcome these limitations. Specifically, while varying physical requirements have been usually met by designing the locator devices for a specific market (for example to be installed in vehicles or containers), the only solution to the varying functional requirements has been to develop custom software and firmware loads for each customer and/or application. There are many disadvantages to that solution: design and support costs requirement to develop and maintain a multitude of software streams; slow request-to-implementation time as any requested feature has to be integrated into existing software and the entire fleet of devices has to be upgraded; and lack of flexibility as each locator device can only operate a single feature set at any one time. Furthermore, this cumbersome approach did not solve the issue of a single locator device, which may have different operational profiles not based on the customer who is using it, but on a more transient quality such as where the locator device may be located or what the vehicle or asset with that locator device is doing at that time. Further still, existing solutions allow only for reporting, or other actions, based upon entering or exiting a geofence, and do not allow for taking configurable actions based on an inherent aspect of the geofence.